home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / pc / TUT04NEW.ZIP / TUT4.TXT < prev   
Encoding:
Text File  |  1994-12-23  |  9.6 KB  |  265 lines
  1.                    ╒═══════════════════════════════╕
  2.                    │         W E L C O M E         │
  3.                    │  To the VGA Trainer Program   │ │
  4.                    │              By               │ │
  5.                    │      DENTHOR of ASPHYXIA      │ │ │
  6.                    │      (updated by Snowman)     │ │ │
  7.                    ╘═══════════════════════════════╛ │ │
  8.                      ────────────────────────────────┘ │
  9.                        ────────────────────────────────┘
  10.  
  11.                            --==[ PART 4 ]==--
  12.  
  13.  
  14. [Note: things in brackets have been added by Snowman.  The original text
  15. has remained mostly unaltered except for the inclusion of C++ material]
  16.  
  17. ■ Introduction
  18.  
  19. Howdy all! Welcome to the fourth part of this trainer series! It's a little
  20. late, but I am sure you will find that the wait was worth it, becase today I
  21. am going to show you how to use a very powerful tool : Virtual Screens.
  22.  
  23. If you would like to contact me, or the team, there are many ways you
  24. can do it : 1) Write a message to Grant Smith in private mail here on
  25.                   the Mailbox BBS.
  26.             2) Write a message here in the Programming conference here
  27.                   on the Mailbox (Preferred if you have a general
  28.                   programming query or problem others would benefit from)
  29.             3) Write to ASPHYXIA on the ASPHYXIA BBS.
  30.             4) Write to Denthor, Eze or Livewire on Connectix.
  31.             5) Write to :  Grant Smith
  32.                            P.O.Box 270 Kloof
  33.                            3640
  34.             6) Call me (Grant Smith) at 73 2129 (leave a message if you
  35.                   call during varsity)
  36.  
  37. NB : If you are a representative of a company or BBS, and want ASPHYXIA
  38.        to do you a demo, leave mail to me; we can discuss it.
  39. NNB : If you have done/attempted a demo, SEND IT TO ME! We are feeling
  40.         quite lonely and want to meet/help out/exchange code with other demo
  41.         groups. What do you have to lose? Leave a message here and we can work
  42.         out how to transfer it. We really want to hear from you!
  43.  
  44.  
  45. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  46. ■  What is a Virtual Screen and why do we need it?
  47.  
  48. Let us say you are generating a complex screen numerous times on the fly
  49. (for example scrolling up the screen then redrawing all the sprites for
  50. each frame of a game you are writing.) Do you have any idea how awful it
  51. would look if the user could actually see you erasing and redrawing each
  52. sprite for each frame? Can you visualise the flicker effect this would
  53. give off? Do you realise that there would be a "sprite doubling" effect
  54. (where you see two copies of the same sprite next to each other)? In the
  55. sample program I have included a part where I do not use virtual screens
  56. to demonstrate these problems. Virtual screens are not the only way to
  57. solve these problems, but they are definately the easiest to code in.
  58.  
  59. A virtual screen is this : a section of memory set aside that is exactly
  60. like the VGA screen on which you do all your working, then "flip" it
  61. on to your true screen. In EGA 640x350x16 you automatically have a
  62. virtual page, and it is possible to have up to four on the MCGA using a
  63. particular tweaked mode, but for our puposes we will set one up using base
  64. memory.
  65.  
  66. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  67. ■  Setting up a virtual screen
  68.  
  69. As you will have seen in the first part of this trainer series, the MCGA
  70. screen is 64000 bytes big (320x200=64000). You may also have noticed that
  71. in TP 6.0 [and C++] you arn't allowed too much space for normal variables.
  72. For example, saying :
  73.  
  74. [Pascal]
  75.  
  76.   VAR Virtual : Array [1..64000] of byte;
  77.  
  78. [C++]
  79.  
  80.   unsigned char Virtual[64000];
  81.  
  82. would be a no-no, as you wouldn't have any space for your other variables.
  83. What is the solution? I hear you enquiring minds cry. The answer : pointers!
  84. Pointers to not use up the base 64k allocated to you by TP 6.0 [and C++], it
  85. gets space from somewhere else in the base 640k memory of your computer. Here
  86. is how you set them up :
  87.  
  88. [Pascal]
  89.  
  90.   Type Virtual = Array [1..64000] of byte;  { The size of our Virtual Screen }
  91.        VirtPtr = ^Virtual;                  { Pointer to the virtual screen  }
  92.  
  93.   VAR Virscr : VirtPtr;                     { Our first Virtual screen       }
  94.       Vaddr  : word;                        { Segment of our virtual screen  }
  95.  
  96. [C++] [Note: For simplicity's sake, I have decided to handle the memory
  97.       allocation differently in the translation to C++ code]
  98.  
  99.   unsigned char *vaddr = NULL;             // Pointer to the virtual screen //
  100.  
  101. If you put this in a program as it stands, and try to acess VirScr [or vaddr],
  102. your machine will probably crash. Why? Because you have to get the memory for
  103. your pointers before you can acess them! You do that as follows :
  104.  
  105. [Pascal]
  106.  
  107.   Procedure SetUpVirtual;
  108.   BEGIN
  109.     GetMem (VirScr,64000);
  110.     vaddr := seg (virscr^);
  111.   END;
  112.  
  113. [C++]
  114.  
  115.   void SetUpVirtual() {
  116.     vaddr = (unsigned char *) calloc(64000,1);
  117.   }
  118.  
  119. This procedure has got the memory for the screen, then set vaddr to the
  120. screens segment. DON'T EVER LEAVE THIS PROCEDURE OUT OF YOUR PROGRAM!
  121. If you leave it out, when you write to your virtual screen you will probably
  122. be writing over DOS or some such thing. Not a good plan ;-).
  123.  
  124. When you have finished your program, you will want to free the memory
  125. taken up by the virtual screen by doing the following :
  126.  
  127. [Pascal]
  128.  
  129.   Procedure ShutDown;
  130.   BEGIN
  131.     FreeMem (VirScr,64000);
  132.   END;
  133.  
  134. [C++]
  135.  
  136.   void ShutDown() {
  137.     free(vaddr);
  138.   }
  139.  
  140. If you don't do this your other programs will have less memory to use for
  141. themselves.
  142.  
  143. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  144. ■  Putting a pixel to your virtual screen
  145.  
  146. This is very similar to putting a pixel to your normal MCGA screen, as
  147. discussed in part one... here is our origonal putpixel :
  148.  
  149. [Pascal]
  150.  
  151.   Procedure PutPixel (X,Y : Integer; Col : Byte);
  152.   BEGIN
  153.     Mem [VGA:X+(Y*320)]:=col;
  154.   END;
  155.  
  156. [C++]
  157.  
  158.   void Putpixel (int x, int y, unsigned char Col) {
  159.     memset(vga+(x+(y*320)),Col,1);
  160.   }
  161.  
  162. For our virtual screen, we do the following :
  163.  
  164. [Pascal]
  165.  
  166.   Procedure VirtPutPixel (X,Y : Integer; Col : Byte);
  167.   BEGIN
  168.     Mem [Vaddr:X+(Y*320)]:=col;
  169.   END;
  170.  
  171. [C++]
  172.  
  173.   void Putpixel (int x, int y, unsigned char Col) {
  174.     memset(vaddr+(x+(y*320)),Col,1);
  175.   }
  176.  
  177.  
  178. It seems quite wasteful to have two procedures doing exactly the same thing,
  179. just to different screens, doesn't it? So why don't we combine the two like
  180. this :
  181.  
  182. [Pascal]
  183.  
  184.   Procedure PutPixel (X,Y : Integer; Col : Byte; Where : Word);
  185.   BEGIN
  186.     Mem [Where:X+(Y*320)]:=col;
  187.   END;
  188.  
  189. [C++]
  190.  
  191.   void Putpixel (int x, int y, unsigned char Col, unsigned char *Where) {
  192.     memset(Where+(x+(y*320)),Col,1);
  193.   }
  194.  
  195. To use this, you will say something like :
  196.  
  197. Putpixel (20,20,32,VGA);
  198. PutPixel (30,30,64,Vaddr);
  199.  
  200. These two statements draw two pixels ... one to the VGA screen and one to
  201. the virtual screen! Doesn't that make you jump  with joy! ;-) You will
  202. have noticed that we still can't actually SEE the virtual screen, so on to
  203. the next part ...
  204.  
  205. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  206. ■  How to "Flip" your virtual screen on to the true screen
  207.  
  208. You in fact already have to tools to do this yourselves from information
  209. in the previous parts of this trainer series. We will of course use the
  210. Move [_fmemcpy] command, like so :
  211.  
  212. [Pascal]
  213.  
  214.   Move (Virscr^,mem [VGA:0],64000);
  215.  
  216. [C++]
  217.  
  218.   _fmemcpy(vga,vaddr,64000);
  219.  
  220. simple, eh? You may want to wait for a verticle retrace (Part 2) before you
  221. do that, as it may make the flip much smoother (and, alas, slower).
  222.  
  223. Note that most of our other procedures may be altered to support the
  224. virtual screen, such as Cls etc. (see Part 1 of this series), using the
  225. methoods described above (I have altered the CLS procedure in the sample
  226. program given at the end of this Part.)
  227.  
  228. We of ASPHYXIA have used virtual screens in almost all of our demos.
  229. Can you imagine how awful the SoftelDemo would have looked if you had to
  230. watch us redrawing the moving background, text and vectorballs for EACH
  231. FRAME? The flicker, doubling effects etc would have made it awful! So
  232. we used a virtual screen, and are very pleased with the result.
  233. Note, though, that to get the speed we needed to get the demo fast enough,
  234. we wrote our sprites routines, flip routines, pallette routines etc. all
  235. in assembly. The move command is very fast, but not as fast as ASM ;-)
  236.  
  237. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  238. ■  In closing
  239.  
  240. I am writing this on the varsity computers in between lectures. I prefer
  241. writing & coding between 6pm and 4am, but it isn't a good plan when
  242. varsity is on ;-), so this is the first part of the trainer series ever
  243. written before 9pm.
  244.  
  245. I have been asked to do a part on scrolling the screen, so that is
  246. probably what I will do for next week. Also, ASPHYXIA will soon be putting
  247. up a small demo with source on the local boards. It will use routines
  248. that we have discussed in this series, and demonstrate how powerful these
  249. routines can be if used in the correct manner.
  250.  
  251. Some projects for you to do :
  252.   1) Rewrite the flip statement so that you can say :
  253.         flip (Vaddr,VGA);
  254.         flip (VGA,Vaddr);
  255.       ( This is how ASPHYXIAS one works )
  256.  
  257.   2) Put most of the routines (putpixel, cls, pal etc.) into a unit,
  258.      so that you do not need to duplicate the procedures in each program
  259.      you write. If you need help, leave me mail.
  260.  
  261.  
  262. See you next week
  263.    - Denthor
  264.  
  265.